Slime <fak### [at] emailaddress> wrote:
> right image_width/image_height

  You mean "right x*image_width/image_height"?

> though many (including myself) consider this bad style when used for
> anything but quick test scenes, since it makes the image difficult to render
> with a non-1:1 pixel aspect ratio, which is useful and necessary in some
> cases.

  Using the automatic aspect ratio (to always get 1:1 pixels) like above
sounds tempting at first, but as you said, it's actually not necessarily
a good idea with most scenes.

  What one does not immediately realize (before making actual tests) is
that adjusting the aspect ratio of the camera with the 'right' or the 'up'
keywords always adjusts it vertically (regardless of which one of them is
used, which comes as a surprise to most). That is, if you change the
aspect ratio of the camera, part of the scene will go out of the image
or additional scenery will appear in the upper and lower sides of the
image. The horizontal range of view will keep constant (it can't be
adjusted with 'right' nor 'up').

  More often than not, if a scene is designed to be viewed at different
aspect ratios, it's usually designed so that the viewing range can be
freely modified horizontally. This is very typical in eg. outdoor scenes.
That is, if you render a wider image, more scenery appears at the sides
of the image. It's quite rare that scenery is designed so that interesting
new parts can come to view if the image is enlarged vertically.
  In these types of scenes having an automatic aspect ratio correction
in the camera would not be helpful at all: Changing the aspect ratio will
not change the horizontal viewing area.

  However, this is actually not the main problem: The main problem is
that it's not at all unusual that only visible parts of the scene are
modelled, while the parts of the scene outside the viewing area are
modelled with less accuracy or not at all. For example, someone could
model a brick wall just up to the altitude that it covers the intended
image.
  This means that if the scene had automatic aspect ratio correction and
someone happens to render an image with a different aspect ratio, some
parts of the scenery may become visible (at the top and bottom of the
image) which were never intended to be shown.
  Moreover, if this someone renders a scene with the aspect ratio set
to the other direction, parts of the original scene will end up out of
the image, perhaps even clipping something important in the original
image.
  I assume this is seldom what the original author had in mind.

  This phenomenon is also bad in that if someone rendered an image like
this with a different aspect ratio, chances are big that he would not
notice there is something wrong with the image. If due to the clipping
or extra unwanted scenery coming to view the overall quality of the
image suffers, this person could just think the author sucks.
  On the other hand, if the scene had no automatic correction, what
the user would get is a squeezed image which has a higher probability
of alerting him that something has gone wrong. (Even though the modern
convert-4:3-tv-image-to-16:9-tv-by-squeezing generation might actually
not see anything wrong, but that's a different story.)

  Also, as you said, if someone *wants* to render the image with
non-square pixels (one example being the Windows startup image),
the automatic aspect ratio correction would only cause trouble.

  Now, what if someone really wants an automatic aspect ratio correction
which does it *horizontally* instead of vertically (which might be quite
feasible with some scenes)?
  This is a much less trivial thing to do. In order to do this one would
have to change both 'right' and 'angle' values of the camera in such way
that the vertical visual range would not change but only the horizontal.
The correct formula to do this is something I have yet to see.

  (Hmm... Would this subject make a good entry in the povQ&T site?)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message